[JENKINS-47213] Opening a PR when the branch is still building with "Exclude branches that are also filed as PRs" leads to a never ending build in BitBucket #930
Conversation
nfalco79
force-pushed
the
feature/notification_refname
branch
from
407c1b5 to
03e4c20
Compare
|
Installed in our production |
That documentation is for POST /api/latest/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}/builds. As noted in #621, this plugin is still using the older POST /build-status/1.0/commits/{commitId}, which is instead documented at https://developer.atlassian.com/server/bitbucket/rest/v903/api-group-deprecated/#api-build-status-latest-commits-commitid-post (except the documentation has "latest" rather than "1.0"). This old API is why the build status cannot be deleted, according to https://jira.atlassian.com/browse/BSERV-11393?focusedId=2784874&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2784874. |
|
Good catch, I had forget to update the endpoint for the Server client. However, my hope would be to remove the Server logic and leave it handled by atlassian-bitbucket-server-integration. I am convinced that spending double the time to support both does not make much sense. It is exactly like having two different issues tracking (github/JIRA) for which I have to constantly jump here and there to gather informations, comments and so on... |
nfalco79
force-pushed
the
feature/notification_refname
branch
from
03e4c20 to
830dab9
Compare
|
The Bitbucket Cloud feature request [BCLOUD-15381] DELETE verb for the build status endpoint has six votes in almost seven years; it seems unlikely to be implemented any time soon. |
|
@nfalco79, have you tested this with a pull request from a fork, on Bitbucket Server or Data Center? Or only with the source and target branches in the same a repository? If I understand jenkinsci/atlassian-bitbucket-server-integration-plugin#401 (comment) correctly, the build status should then be posted to the repository that contains the source branch of the pull request. But it isn't clear to me whether this code does so. |
|
Tested with source and target in the same repository. In short any build that does not come from pr is valued with the name of the branch. In case of pr than null. This works for cloud, i hope the same for server. |
nfalco79
force-pushed
the
feature/notification_refname
branch
from
830dab9 to
9367bf9
Compare
Let me see what they will do when they implement the feature (authentication, source reference and so on). No documentation, no gain, no party |
Was that test with Bitbucket Cloud or with Bitbucket Data Center? (I assume you don't have access to Bitbucket Server because you asked me to test with that earlier.) |
|
We have a Bitbucket Cloud account |
Add comments why disableNotifications in BitbucketBuildStatusNotificationsTrait has been disabled. Rename disableNotificationForNotBuildJobs to sendStopNotificationForNotBuildJobs in BitbucketSCMContext to fit real meaning of what that options does. Before commit #200b56ca only for bitbucket server in case of not build result no status was communicated to Bitbucket.
…Exclude branches that are also filed as PRs" leads to a never ending build in BitBucket Bitbucket enhance its build status API with a refname (Cloud) and ref (Server) property to indicate the owner's git reference. This can be used as a sort of filter in case multiple build statuses have been associated with the same commit. For example, this means that when browsing commits from the webpage, you will see all the build statuses associated with a commit (no scope); but, you should only see one when you land on the pull request webpage (scoped). NOTE: At the time of implementation once a build status is created, it cannot be deleted via the API. If refname is set, it cannot be set to null. The property appears to participate in some way in the primary key of the build status, multiple build statuses with the same key but different refnames are allowed, especially in the use case the update APIs return an HTTP 500 error. Available documentations: * https://developer.atlassian.com/server/bitbucket/rest/v903/api-group-builds-and-deployments/#api-api-latest-projects-projectkey-repos-repositoryslug-commits-commitid-builds-post * https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commit-statuses/#api-repositories-workspace-repo-slug-commit-commit-statuses-build-post does not explain precisly how this property should be valued. This force me to set the property to null in case of pull request, otherwise, the build status disappear from the webpage and branch restriction and merge conditions will not work.
nfalco79
force-pushed
the
feature/notification_refname
branch
from
503b549 to
7ac886d
Compare
Bitbucket enhance its build status API with a refname (Cloud) and ref (Server) property to indicate the owner's git reference. This can be used as a sort of filter in case multiple build statuses have been associated with the same commit.
For example, this means that when browsing commits from the webpage, you will see all the build statuses associated with a commit (no scope); but, you should only see one when you land on the pull request webpage (scoped).
NOTE: At the time of implementation once a build status is created, it cannot be deleted via the API. If refname is set, it cannot be set to null. The property appears to participate in some way in the primary key of the build status, multiple build statuses with the same key but different refnames are allowed, especially in the use case the update APIs return an HTTP 500 error.
Available documentations:
does not explain precisly how this property should be valued. This force me to set the property to null in case of pull request, otherwise, the build status disappear from the webpage and branch restriction and merge conditions will not work.
Summary
Bitbucket Cloud
Considering only pages that show the build status, such as:
Steps:
Pull Requests
In the specific "Pull Request" page now shows only the build status binded to the last commit in branch feature/xyz. Build status binded to the same commit in the target branch (example: master) is not listed.
You will see only 1 of 1 build passed.
There is some strange behavior on the "Pull Requests" listing page, let's say you filter by "Merged", the icon on the right in the tooltips shows all build states associated with the commit, BUT if you click on the bitbucket icon it only shows you the build state related to the commit (the same way it did on the specific pull request page above):
Before these changes, all build states associated with the commit were listed:
Commits
In the "Commits" page all build status (regardless the refname value) binded the commit are shown:
Branches
In the "Branches" page all build status (regardless the refname value) binded the commit are shown:
